I had a bit of a look at the code, and i like idea as a concept... but maybe if you are making changes in this area we should stop just throwing 16byte chunks or 32byte chunks over "the wire" without any header/footer/checksum .. or at this early point, start-allowing-both..? ..the only reason it works so well right up-to this point is that sitl/ethernet/udp is so-close to lossless that it might as well be ... but it is a UDP/datagram, and that makes it officially "lossy".

I can imagine it becoming substantially more lossy when running over wifi, or when some part of it is running on an underwhelming bit of hardware , or both ( an esp32 sending/recieving rc sitl packets over wifi for hardware-in-the-loop that is configured to use a "real" RC ?)..?

I'd also like to point out that in my hypothetical implementation that has some-sort-of header bytes, and some-sort-of-checksum.... is that suddenly just a mavlink packet optionally being used for this? I suspect you'd want to support either, and autodetect to fallback to the current behaviour..?

i know, i know its scope creep, so totally unneeded, but the idea occurred to me, so was worth thinking about

I had a bit of a look at the code, and i like idea as a concept... but maybe if you are making changes in this area we should stop just throwing 16byte chunks or 32byte chunks over "the wire" without any header/footer/checksum .. or at this early point, start-allowing-both..? ..the only reason it works so well right up-to this point is that sitl/ethernet/udp is so-close to lossless that it might as well be ... but it is a UDP/datagram, and that makes it officially "lossy".

I can imagine it becoming substantially more lossy when running over wifi, or when some part of it is running on an underwhelming bit of hardware , or both ( an esp32 sending/recieving rc sitl packets over wifi for hardware-in-the-loop that is configured to use a "real" RC ?)..?

I'd also like to point out that in my hypothetical implementation that has some-sort-of header bytes, and some-sort-of-checksum.... is that suddenly just a mavlink packet optionally being used for this? I suspect you'd want to support either, and autodetect to fallback to the current behaviour..?

i know, i know its scope creep, so totally unneeded, but the idea occurred to me, so was worth thinking about

I hope this is structured in a way that you can actually just feed any protocol in on that serial port and it will be parsed out by the appropriate backend. I haven't tested that yet! This is why I mentioned the "baud rate" thing - if we want to be able to parse out CRSF we'd currently need to convince the CRSF backend that this really was 115200 serial!

To your wider point - raw packed 16-bit quantities - I don't think we can get rid of it any time soon. Too much else out there may rely on it.

Note that we could do this very differently, by having the AP_RCProtocol_SITL backend do all of the port binding itself, rather than have the HAL do it. This would let Linux reuse it rather more easily. We'd then need to find some other way to take input via other protocols - bit I believe we may already be able to do that by simply setting a serial port to listen on a network socket and setting the protocol to 23... tests byte-protocols but not pulse-stream protocols...